Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wip/server permissions #174

Merged
merged 3 commits into from
Feb 28, 2014
Merged

Wip/server permissions #174

merged 3 commits into from
Feb 28, 2014

Conversation

muuki88
Copy link
Contributor

@muuki88 muuki88 commented Feb 23, 2014

DONE

This is a follow up to #170 discussions. The current state of the pull request contains

  • Replacing all traces of appUser and appGroup with daemonUser and daemonGroup
  • Using the new MappingsHelper
  • Added defaultLinuxConfigLocation

TODO

Think of a way to create a permissions-table like this

Folder User Permissions Purpose
/usr/share/package-name root 755 / (655) static, non-changeable files
/etc/default/package-name.conf root 644 default config file
/etc/package-name root 644 config folder -> link to /usr/share/package-name/conf
/var/run/package-name daemonUser 664 if the application generates a pid on its own
/var/log/package-name daemonUser 664 log folder -> symlinked from /usr/share/package-name/log

Option 1: mapping-files-changer

A small API to change permissions for already-created mappings.

Pro Contra
Add-in, currenty behaviour doesn't need to be changed LinuxPackageMappings may need to be split, as they contain a sequence of mappings
easy API, e.g. changePermissions(for = "/usr/share", LinuxFileMetaData(user = "daemonUser")) No place to lookup _defaults

Option 2: creating a permissions table

The idea is to define a setting, which can be queried for default permissions, like

val meta: LinuxFileMetaData = permissionsFor "/usr/share"
Pro Contra
defaults can be easily overidden checked before each mapping is created
one place for defaults permission table for dirs, files and maybe more

Discussion

@aparkinson, @jsuereth, @kardapoltsev . What do you think?

@kardapoltsev
Copy link
Member

Since mostly we want default root:root 644 I think the first option will be fine.

@muuki88 muuki88 mentioned this pull request Feb 28, 2014
for((file, name) <- manPages)
yield file -> (name + ".gz")
for ((file, name) <- manPages)
yield file -> (name + ".gz")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT of using Scalariform, which although not my favorite style, will help prevent all of us from whitespace-line changing each other?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm already using it through Eclipse (at least that's what the scalariform page says). However an integration in the build with sbt-scalariform would be helpful as everbody uses another IDE

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jsuereth
Copy link
Member

SO in terms of option 1 vs. Option 2, I'm on the fence. Both have desirable attributes. I'm leaning towards 2 though, for sbt.

rawLinuxPackageMappings as a key that you could then safely filter. I.e. all archetypes feed directly into rawLinuxPackageMappings and then we have a simple:

linuxPackageMappings in Linux := (rawLinuxPackageMappings in Linux).value

@jsuereth
Copy link
Member

Merging this as-is for now.

jsuereth added a commit that referenced this pull request Feb 28, 2014
@jsuereth jsuereth merged commit 676d72c into master Feb 28, 2014
@jsuereth jsuereth deleted the wip/server-permissions branch February 28, 2014 13:34
muuki88 added a commit that referenced this pull request Mar 2, 2014
jsuereth added a commit that referenced this pull request Mar 3, 2014
Implementing permissions as described in #174
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants